src/assets/Hindi.json-1194-1194 (1)

1194-1194: Fix typo in testresult translation.

There's an extra "t" character at the end of the Hindi translation. The value should be "जाँच परिणाम" instead of "जाँच परिणामt".

🔎 Proposed fix

-      "testresult": "जाँच परिणामt",
+      "testresult": "जाँच परिणाम",

src/assets/Kannada.json-2137-2137 (1)

2137-2137: Potential typo in translation key name.

The key name internaleServerError appears to have a typo - it should likely be internalServerError (missing the 'l' before 'Server'). This inconsistency could cause issues when the frontend code tries to reference this translation key.

🔎 Suggested fix

-        "internaleServerError": "ಆಂತರಿಕ ಸರ್ವರ್ ದೋಷ",
+        "internalServerError": "ಆಂತರಿಕ ಸರ್ವರ್ ದೋಷ",

src/assets/English.json-2134-2134 (1)

2134-2134: Fix typo in translation key.

The key internaleServerError contains a typo. It should be internalServerError (note the missing 'l' before 'S' in "Internal"). This typo could cause confusion and may require code changes if corrected later.

🔎 Proposed fix

-        "internaleServerError": "Internal Server Error",
+        "internalServerError": "Internal Server Error",

src/app/app-modules/nurse-doctor/case-record/general-case-record/diagnosis/ncd-screening-diagnosis/ncd-screening-diagnosis.component.html-20-20 (1)

20-20: Validation is handled programmatically but only at button state level—consider enforcing at form control level.

The required attribute removal is balanced by checkProvisionalDiagnosisValidity(), which correctly validates that both term and conceptID are populated. However, this validation only disables the Add button and does not mark the form control as invalid. The form control itself has no required validator, so the form could be submitted as valid even if no diagnosis is selected when enableProvisionalDiag is true. Either add Validators.required to the form control conditionally, or implement form-level validation to ensure incomplete provisional diagnoses are caught at submission.

src/environments/environment.test.ts-73-79 (1)

73-79: Use explicit HTTP protocol for the test tracker URL instead of protocol-relative format.

Matomo documentation explicitly advises against protocol-relative URLs for tracker configuration due to mixed-content warnings, caching issues, and reduced security. For test environments on localhost, use http://127.0.0.1/ instead of //127.0.0.1/.

src/environments/environment.ci.ts.template-59-65 (1)

59-65: Ensure SITE_ID template variable is always numeric during deployment

The siteId field uses parseInt('<%= SITE_ID %>'). While ci-prebuild.js provides a default value of '1', the variable can be overridden by environment variables. If an empty string or non-numeric value is passed, parseInt() will silently return NaN, breaking Matomo tracking. Add validation or document that SITE_ID must always be a numeric string during the build/deployment process.

src/app/app-modules/nurse-doctor/quick-consult/quick-consult.component.ts-1472-1482 (1)

1472-1482: Add validation for deduplication key fields

The deduplication logic relies on items having at least one of id, code, or term, but there is no validation that ensures this. Items lacking all three fields would be keyed as undefined, causing multiple malformed records to incorrectly deduplicate as a single entry. Consider adding a fallback deduplication key (e.g., object stringification) or explicit validation to handle items that lack all three identifiers.

src/app/app-modules/nurse-doctor/case-sheet/general-case-sheet/doctor-diagnosis-case-sheet/doctor-diagnosis-case-sheet.component.ts-583-603 (1)

583-603: Handle potential null userId before downloading signature.

If getUserId() returns null (when res?.userId is falsy) and tCSpecialistUserID is also missing/zero, downloadSign will be called with null, which could cause the API call to fail or return unexpected results.

🔎 Suggested fix

 downloadSign() {
   this.getUserId().subscribe((userId) => {
     const tcSpecId = this.beneficiaryDetails?.tCSpecialistUserID;
     const userIdToUse = tcSpecId && tcSpecId !== 0 ? tcSpecId : userId;
+    if (!userIdToUse) {
+      console.warn('No valid user ID available for signature download');
+      return;
+    }
     this.doctorService.downloadSign(userIdToUse).subscribe(
       (response: any) => {
         const blob = new Blob([response], { type: response.type });
         this.showSign(blob);
       },
       (err: any) => {
         console.error('Error downloading signature:', err);
       },
     );
   });
 }

src/app/app-modules/nurse-doctor/case-record/general-case-record/diagnosis/ncd-screening-diagnosis/ncd-screening-diagnosis.component.ts-552-554 (1)

552-554: Missing optional chaining on unsubscribe() call.

Unlike GeneralOpdDiagnosisComponent which uses unsubscribe?.(), this component calls unsubscribe() directly. Since MMUdiagnosisSubscription is typed as any, it could throw if the subscription completed abnormally or was never initialized. Consider using optional chaining for consistency and safety.

🔎 Proposed fix

    if (this.MMUdiagnosisSubscription) {
-     this.MMUdiagnosisSubscription.unsubscribe();
+     this.MMUdiagnosisSubscription.unsubscribe?.();
    }

src/app/app.component.ts-4-4 (1)

4-4: Remove the unused AmritTrackingService import and injection, and delete the debug console.log.

AmritTrackingService is imported and injected in the constructor but never used in the component. Other components across the codebase actively call trackFieldInteraction() or setUserId() on this service, but AppComponent has no such calls. Additionally, the console.log('success') in ngOnInit should be removed.

src/assets/Kannada.json (1)

2135-2138: Consider organizing these keys under a subsection for consistency.

The new translation keys (continueButton, accessDenied, internalServerError, somethingWentWrong) are placed directly at the root Kannada object level, while similar error/alert messages throughout the file are organized under the alerts.info section (see line 1193 for example).

For better maintainability and consistency with the existing structure, consider moving these keys to an appropriate subsection like alerts.info or creating a new logical grouping (e.g., common.buttons, common.errors).

Example organization approach

         "alerts": {
             "info": {
                 "beneficiaryNotFound": "ಫಲಾನುಭವಿಯು ಡೇಟಾ ಕಂಡುಬಂದಿಲ್ಲ",
+                "accessDenied": "ಪ್ರವೇಶ ನಿರಾಕರಿಸಲಾಗಿದೆ",
+                "internalServerError": "ಆಂತರಿಕ ಸರ್ವರ್ ದೋಷ",
+                "somethingWentWrong": "ಏನೋ ತಪ್ಪಾಗಿದೆ",
                 ...
             }
         },
+        "common": {
+            "continueButton": "ಮುಂದುವರಿಸಿ",
+            ...
+        }

src/app/app-modules/nurse-doctor/history/general-opd-history/personal-history/personal-history.component.html (2)

10-696: Consider using constants for tracking field names.

The tracking calls use string literals throughout (e.g., 'Previous Tobacco History', 'Dietary Type'). Consider defining these as constants to prevent typos and improve maintainability.

Example approach

In the component TypeScript file, define constants:

const TRACKING_FIELDS = {
  PREVIOUS_TOBACCO: 'Previous Tobacco History',
  PREVIOUS_ALCOHOL: 'Previous Alcohol History',
  DIETARY_TYPE: 'Dietary Type',
  // ... etc
} as const;

Then use in the template:

(click)="getPreviousTobaccoHistory(); trackFieldInteraction(TRACKING_FIELDS.PREVIOUS_TOBACCO)"

However, since template expressions have limited access to component properties, you may need to expose these constants via a getter or use them in component methods instead.

---

256-666: Consider the volume of tracking events being generated.

Tracking has been added to high-frequency events including focus handlers on multiple input fields. While valuable for analytics, this could generate substantial telemetry data, especially in busy clinical environments.

Consider:

• Whether focus events are necessary for your analytics goals, or if change/blur events would suffice
• Implementing sampling or throttling for high-frequency events
• Monitoring the performance and storage impact of the tracking service

src/app/app-modules/nurse-doctor/case-record/general-case-record/diagnosis/pnc-diagnosis/pnc-diagnosis.component.html (1)

65-69: Move inline styles to CSS file.

The flexbox centering styles are duplicated in both the provisional and confirmatory diagnosis sections. Extract these to a reusable CSS class in the component's stylesheet for better maintainability.

🔎 Proposed fix

Add to pnc-diagnosis.component.css:

.diagnosis-button-container {
  display: flex;
  justify-content: center;
  align-items: center;
}

Then update the template:

-              style="
-                display: flex;
-                justify-content: center;
-                align-items: center;
-              "
+              class="diagnosis-button-container"

Also applies to: 168-172

src/app/app-modules/nurse-doctor/case-record/general-case-record/diagnosis/pnc-diagnosis/pnc-diagnosis.component.ts (1)

441-458: Consider using a typed interface for state management.

The state object uses parallel arrays indexed by position, which can be error-prone. The arrays are not pre-initialized, so accessing state.provisional.suggested[i] when index i hasn't been used yet returns undefined.

🔎 Proposed improvement with typed interface

interface DiagnosisState {
  suggested: any[];
  lastQuery: string;
  page: number;
  loadingMore: boolean;
  noMore: boolean;
  wantMore: boolean;
}

state: {
  provisional: Map<number, DiagnosisState>;
  confirmatory: Map<number, DiagnosisState>;
} = {
  provisional: new Map(),
  confirmatory: new Map(),
};

// Helper to get or create state for an index
private getOrCreateState(type: 'provisional' | 'confirmatory', index: number): DiagnosisState {
  const map = this.state[type];
  if (!map.has(index)) {
    map.set(index, {
      suggested: [],
      lastQuery: '',
      page: 0,
      loadingMore: false,
      noMore: false,
      wantMore: false,
    });
  }
  return map.get(index)!;
}

src/app/app-modules/nurse-doctor/shared/utility/autocomplete-scroller.directive.ts (1)

67-67: Consider refactoring to avoid non-null assertion.

The non-null assertion on this.scrollListener! at line 67 is technically safe since the listener is assigned just above on line 58. However, to address the linter warning and improve code clarity, consider this refactor:

🔎 Proposed refactor to eliminate non-null assertion

         this.ngZone.runOutsideAngular(() => {
-          this.scrollListener = () => {
+          const listener = () => {
             if (panelEl.scrollHeight <= panelEl.clientHeight) return; // no overflow yet
             const ratio =
               (panelEl.scrollTop + panelEl.clientHeight) / panelEl.scrollHeight;
             if (ratio >= this.threshold) {
               // hop back into Angular so change detection works
               this.ngZone.run(() => this.nearEnd.emit());
             }
           };
-          panelEl.addEventListener('scroll', this.scrollListener!, {
+          this.scrollListener = listener;
+          panelEl.addEventListener('scroll', listener, {
             passive: true,
           });
         });

src/app/app-modules/nurse-doctor/case-record/general-case-record/findings/findings.component.html (1)

14-14: Overly broad tracking scope on table click.

The tracking call fires on any click within the entire table, including clicks on individual cells, rows, and interactive elements. This may generate excessive tracking events and make it difficult to distinguish between different user actions within the table.

Consider tracking more specific interactions (e.g., row clicks, specific cell interactions) or moving this to individual interactive elements within the table.

src/app/app-modules/nurse-doctor/doctor-worklist/doctor-worklist.component.css (1)

99-102: Note: ::ng-deep is deprecated in Angular.

While ::ng-deep still works, it's officially deprecated. For component-specific styling that needs to pierce view encapsulation, consider using :host ::ng-deep or moving these styles to a global stylesheet if they're meant to be application-wide.

Regarding the static analysis hints flagging ::ng-deep as an unknown pseudo-element: this is a false positive, as Biome doesn't recognize Angular-specific pseudo-elements.

Alternative approach using :host

-::ng-deep .marker-h-r-c,
-::ng-deep .marker-h-r-c td {
+:host ::ng-deep .marker-h-r-c,
+:host ::ng-deep .marker-h-r-c td {
   color: #FF0000 !important;
 }

This scopes the styling to this component's view, providing better encapsulation.

src/app/app-modules/nurse-doctor/examination/general-opd-examination/systemic-examination/respiratory-system/respiratory-system.component.html (1)

12-214: Tracking integration looks good with a minor consideration.

The telemetry tracking is properly integrated across all form controls with appropriate event types for each control. The event selection is correct (selectionChange for dropdowns, focus for textareas, change for radio buttons).

Optional: Consider that focus events on textareas (lines 38, 77) may fire frequently if users navigate between fields. Ensure the tracking service implements debouncing or deduplication to avoid excessive telemetry data.

src/app/app-modules/nurse-doctor/shared/services/doctor.service.ts (1)

3018-3020: Verify the response type casting.

The responseType: 'blob' as 'json' casting may cause TypeScript type mismatches. Consider using responseType: 'blob' without the cast and updating the return type to Observable<Blob>.

🔎 Proposed fix

-  downloadSign(userID: any) {
-    return this.http.get(environment.downloadSignUrl + userID, {
-      responseType: 'blob' as 'json',
-    });
+  downloadSign(userID: any): Observable<Blob> {
+    return this.http.get(environment.downloadSignUrl + userID, {
+      responseType: 'blob',
+    }) as Observable<Blob>;
   }

src/app/app-modules/nurse-doctor/case-record/general-case-record/diagnosis/diagnosis.component.html (1)

14-14: Consider more granular event tracking for field interactions.

Using click events on component containers will fire for all child element clicks, potentially causing excessive or duplicate tracking events. For field interaction tracking, consider using focus, blur, or change events on individual form controls within each diagnosis component instead of a single click handler on the container.

Also applies to: 20-20, 26-26, 32-32, 38-38, 44-44

src/app/app-modules/nurse-doctor/history/general-opd-history/past-history/past-history.component.html (1)

51-52: LGTM with minor suggestion.

The tracking integration is implemented correctly. The multiple statements in template expressions (lines 51 and 186) work but consider extracting them to component methods for better readability and maintainability.

Optional refactor example

In the component TypeScript file, add:

onPastIllnessChange(value: any, index: number, pastIllness: any) {
  this.filterPastIllnessType(value, index, pastIllness);
  this.trackFieldInteraction('Past Illness');
}

Then update the template:

-(selectionChange)="filterPastIllnessType($event.value, i, pastIllness); trackFieldInteraction('Past Illness')"
+(selectionChange)="onPastIllnessChange($event.value, i, pastIllness)"

Also applies to: 186-187

src/app/app-modules/core/services/http-service.service.ts (1)

25-31: Add error handling for JSON.parse to prevent initialization failures.

If localStorage.getItem('appLanguage') returns corrupted JSON, JSON.parse will throw an exception and crash the service initialization. Consider wrapping this in a try-catch block with a fallback to null.

🔎 Proposed fix with error handling

  constructor(
    private _http: HttpClient,
    private http: HttpClient,
  ) {
    const storedLang = localStorage.getItem('appLanguage');
-   this.language = storedLang ? JSON.parse(storedLang) : null;
+   try {
+     this.language = storedLang ? JSON.parse(storedLang) : null;
+   } catch (error) {
+     console.error('Failed to parse language from localStorage:', error);
+     this.language = null;
+     localStorage.removeItem('appLanguage');
+   }

    this.appCurrentLanguge = new BehaviorSubject(this.language);
    this.currentLangugae$ = this.appCurrentLanguge.asObservable();
  }

src/app/app-modules/nurse-doctor/quick-consult/quick-consult.component.ts (1)

1492-1494: Consider user-facing error feedback

The error handler logs to console.error but doesn't provide user-facing feedback. Consider showing a dismissible notification or inline message so users know the search failed and can retry.

Suggested improvement

       error: () => {
         console.error('Error fetching diagnosis data');
+        this.confirmationService.alert(
+          this.currentLanguageSet?.alerts?.info?.errorFetchingDiagnosis || 'Error fetching diagnosis suggestions',
+          'error'
+        );
       },

src/app/app-modules/nurse-doctor/history/general-opd-history/family-history/family-history.component.html (1)

106-106: Remove extraneous blank line.

Line 106 contains an unnecessary blank line that should be removed for consistency.

🔎 Proposed fix

              (selectionChange)="trackFieldInteraction('Family Member')"
-              
            >

src/app/app-modules/nurse-doctor/history/general-opd-history/medication-history/medication-history.component.html (1)

102-102: Remove extraneous blank line.

Line 102 contains an unnecessary blank line that should be removed for consistency.

🔎 Proposed fix

            (click)="addMedicationHistory(); trackFieldInteraction('Add Medication')"
          >
            {{ currentLanguageSet?.common?.add }}
          </button>
-

          <button

src/app/app-modules/nurse-doctor/case-record/general-case-record/diagnosis/ncd-care-diagnosis/ncd-care-diagnosis.component.ts (1)

66-75: Pagination state variables are well-structured for per-index isolation.

The use of separate arrays (loadingMore, noMore, wantMore, pageByIndex, lastQueryByIndex) correctly isolates pagination state per diagnosis row, preventing cross-contamination between concurrent searches.

However, pageSize (line 67) is declared but never used in the implementation.

🔎 Remove unused variable

 private readonly PAGE_BASE = 0;
-pageSize: number | undefined = undefined;

src/app/app-modules/nurse-doctor/case-record/general-case-record/diagnosis/general-opd-diagnosis/general-opd-diagnosis.component.ts (1)

67-76: Unused pageSize property.

The pageSize property is declared but never assigned or referenced anywhere in the component. If it's intended for future use, consider removing it until needed to avoid dead code.

🔎 Suggested removal

  private readonly PAGE_BASE = 0;
-  pageSize: number | undefined = undefined;
-
  private readonly BOOTSTRAP_MAX_PAGES = 3; // when first page can't scroll, prefill up to this many extra pages

src/app/app-modules/nurse-doctor/case-record/general-case-record/diagnosis/ncd-screening-diagnosis/ncd-screening-diagnosis.component.ts (2)

101-110: Unused pageSize property (same as general-opd-diagnosis).

pageSize is declared but never used. Consider removing it to reduce dead code.

---

557-691: Consider extracting pagination logic to a shared utility.

The lazy-loading pagination logic (fetchPage, bootstrapUntilScrollable, onPanelReady, onAutoNearEnd, onDiagnosisInputKeyup) is duplicated across multiple diagnosis components. Extracting this to a shared base class, mixin, or service would reduce maintenance burden and ensure consistent behavior/fixes across all components.

This is a low-priority suggestion for future improvement.

src/app/app.component.ts (1)

20-22: Consider removing debug console.log.

The console.log('success') statement appears to be a debug artifact with no functional purpose.

🔎 Proposed cleanup

 ngOnInit() {
-  console.log('success');
 }

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Learnt from: devikasuresh20
Repo: PSMRI/HWC-UI PR: 66
File: src/app/app-modules/nurse-doctor/visit-details/visit-details/visit-details.component.ts:368-393
Timestamp: 2024-11-15T10:53:55.353Z
Learning: In `src/app/app-modules/nurse-doctor/visit-details/visit-details/visit-details.component.ts`, when the user is focusing on resolving specific issues without undertaking broader refactoring of pre-existing code, avoid suggesting refactoring of existing methods like `getVisitDetails` and `getMMUVisitDetails`.

Learnt from: devikasuresh20
Repo: PSMRI/HWC-UI PR: 122
File: src/app/app-modules/core/components/open-previous-visit-details/open-previous-visit-details.component.html:100-105
Timestamp: 2025-06-02T11:55:35.377Z
Learning: The HWC-UI codebase uses nested `<tr>` elements within `<td>` elements as part of the existing implementation pattern across multiple components in files like `src/app/app-modules/core/components/open-previous-visit-details/open-previous-visit-details.component.html`. Refactoring this HTML table structure would require changes across multiple components and should be considered as a separate, larger refactoring effort.

Learnt from: devikasuresh20
Repo: PSMRI/HWC-UI PR: 66
File: src/app/app-modules/nurse-doctor/visit-details/visit-details/visit-details.component.ts:278-307
Timestamp: 2024-11-15T10:51:41.609Z
Learning: In the `HWC-UI` project, when accessing nested properties of `value.data`, such as `value.data.NCDCareNurseVisitDetail.fileIDs` in `visit-details.component.ts`, the properties are guaranteed to exist, and null checks are already added for `value.data`. Therefore, additional null checks for nested properties are not necessary.

Learnt from: helenKaryamsetty
Repo: PSMRI/HWC-UI PR: 50
File: src/app/app-modules/nurse-doctor/workarea/workarea.component.ts:4219-4228
Timestamp: 2024-11-13T11:08:50.964Z
Learning: In the function `getMappedAbdmFacility()` in `src/app/app-modules/nurse-doctor/workarea/workarea.component.ts`, the `loginDataResponse` retrieved from `localStorage` is guaranteed to be available and properly formatted; therefore, null checks and error handling for this data are unnecessary.

Learnt from: devikasuresh20
Repo: PSMRI/HWC-UI PR: 61
File: src/assets/Hindi.json:2090-2090
Timestamp: 2024-10-28T12:29:22.526Z
Learning: For the `Hindi.json` translation file, when adding new messages and the Hindi translation is not yet available, it's acceptable to temporarily leave the message in English and update it later when the translation is provided by PSMRI.

Learnt from: 5Amogh
Repo: PSMRI/HWC-UI PR: 123
File: src/app/user-login/captcha-service/captcha.service.ts:15-15
Timestamp: 2025-06-03T06:55:03.688Z
Learning: In the PSMRI/HWC-UI project, empty environment variable values like captchaChallengeURL are intentional as proper values are provided by the development team before the application runs as part of their deployment process.

Learnt from: helenKaryamsetty
Repo: PSMRI/HWC-UI PR: 77
File: src/environments/environment.development.ts:48-48
Timestamp: 2024-12-12T10:56:30.617Z
Learning: In the project, the `abhaExtension` variable is set to `sbx` in `environment.development.ts` and `environment.test.ts` for development and test environments, while it is set to `abdm` in `environment.prod.ts` for the production environment.

Learnt from: devikasuresh20
Repo: PSMRI/HWC-UI PR: 144
File: src/app/user-login/service/service.component.ts:185-187
Timestamp: 2025-06-30T11:22:52.940Z
Learning: In src/app/user-login/service/service.component.ts, the loginData retrieved from session storage in the getServicePointAsync method is guaranteed to be available before this flow executes, so null checks before JSON.parse are unnecessary.

Learnt from: devikasuresh20
Repo: PSMRI/HWC-UI PR: 61
File: src/assets/English.json:2094-2094
Timestamp: 2024-10-28T12:30:24.342Z
Learning: In the `src/assets/English.json` file, duplicate translation keys are intentionally kept because they are used in multiple components.

Learnt from: 5Amogh
Repo: PSMRI/HWC-UI PR: 123
File: src/app/user-login/login/login.component.ts:55-55
Timestamp: 2025-06-03T06:54:14.135Z
Learning: In src/app/user-login/login/login.component.ts, the captchaToken property uses definite assignment assertion (!) without explicit initialization, but this is safe because the login button is disabled until the CAPTCHA is successfully resolved, ensuring the property is always defined when accessed in the login method.

Learnt from: 5Amogh
Repo: PSMRI/HWC-UI PR: 123
File: src/app/user-login/login/login.component.ts:349-351
Timestamp: 2025-06-03T06:52:56.725Z
Learning: In src/app/user-login/login/login.component.ts, the onCaptchaResolved method parameter uses `any` type instead of `string` because the Cloudflare Turnstile CAPTCHA library's resolution function emits events that don't statically define the return type as string, and using `string` type causes HTML template compilation errors.